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REMARKS 

Claims 5, 14, 29, and 34 were previously canceled. Claims 1-4, 6-13, 15-28, 30-33, and 
35-36 were pending in the present application. In this Reply, applicants have amended claims 1 
and 1 7. Support for the amendments can be found in applicants' specification as filed in at least 
page 9, *l [0079], page 10, t [0086], page 15, ^ [01 18], and page 61, t [0422]. The amendments 
do not contain new matter. Claims 4, 28, and 30 are canceled without prejudice. 

After entry of the amendments, claims 1-3, 6-13, 15-27, 31-33, and 35-36 remain pending 
in tlie present application. Apphcants submit that these claims are allowable, as discussed 
below. 

Summary of the Office Action 

Claims 1, 7-13, 15-22, 24-27, 30-33, and 35 were rejected under 35 U.S.C. § 103(a) as 
being unpatentable over U.S. Patent Application Publication No. 2003/0004853, to Ram et al. 
(hereinafter "Ram") in view of U.S. Patent Application Publication No. 2003/0212761, to 
Meredith et al. (hereinafter "Meredith"). 

Claims 2, 3, 6 and 36 were rejected under 35 U.S.C. § 103(a) as being unpatentable over 
Ram in view of Meredith and further in view of U.S. Patent Application Publication No. 
2004/022 1066, to Ganfield et al. (hereinafter "Ganfield"). 

Claims 4 and 28 were rejected under 35 U.S.C. § 103(a) as being unpatentable over Ram 
in view of Meredith and further in view of U.S. Patent Application Publication No. 
2007/0199056, to Bhatia et al. (hereinafter "Bhatia"). 

Claim 23 was were rejected under 35 U.S.C. § 103(a) as being unpatentable over Ram in 
view of Meredith and further in view of U.S. Patent Application Publication No. 2005/0144226, 
to Purewal et al. (hereinafter "Purewal"). 

Applicants traverse these rejections for the reasons below. 

35 U.S.C. § 103(a) 

Applicants recognized deficiencies in the then-existing technology: 

Typically, front-end business applications have been integrated with back-office 
host and network-based applications through a complex and non-standard set of 
APIs, adapters, and services. This may be thought of as a product-driven 
approach, since it has multiple products interfacing with the back office, each 



DBl 1)2447542 I 



7 



Application Serial No.: 10/799,227 



through its own set of integration, access, and security mechanisms. . . . 
Regarding the back-end, there may be multiple vendor-supported middleware 
solutions in place, and there may be direct coupling of applications to an 
individual cormectivity utility. (Applicants' specification as filed, p.l, If [0002] - 
[0004]). 

Applicants' disclosed technology differs from the then-existing technology: 

One goal of [applicants' disclosed technology] was to move from a product- 
driven model that consisted of multiple products interfacing with a back office 
through their own integration, access, and security mechanisms (depicted in FIG. 
2) to a channel-driven model that enables multiple products to interface with a 
back office in a consistent and scalable manner (see FIG. 3). (Id., p.ll, f [0091]). 

Specifically, appHcants' disclosed technology "provides a mechanism to insulate 
applications from the many ways in which a service may be implemented, based not on who 
implements the services (vendor, back office, or other party) or how the services get 
implemented, but rather on what the requirements for the services are." (Id., p.9, | [0080]). 
Applicants refer to this mechanism as "integration framework / IF." IF provides "an abstraction 
layer that protects vendors from changes to the services and the back office." (Id., p. 12-13, 
^1 [0098]). The IF "provides a 'screen' behind which back end business appHcations and data can 
evolve over time." (Id., p. 12, t [0095]). 

The descriptions above and other portions from applicants' specification show the 
meaning of and the relationship between "front-end", "back-end", and "absfraction layer" used 
throughout the specification and in applicants' claims. In short, using IF, front-end applications 
communicate with back-end services through an abstraction layer. When back-end services 
evol \ c or change, the abstraction layer insulates the front-end applications from these changes 
such that there is no need to make corresponding changes in the front-end applications to keep 
them running. 



Claims 1-3, 6-13, 15-27 

in accordance with the foregoing, independent claim 1, as amended, recites: 

1 . A system for implementing computer network services and applications, 
comprising: 

a front-end component comprising more than one software apphcation; 
a back-end component comprising one or more software services; and 
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an abstraction layer component that communicates with each of said more 
than one software apphcation in said front-end component and each of said one or 
more software services in said back-end component, wherein: 

said abstraction layer component provides standardization of back 
end services such that each of said more than one software application in said 
front-end component accesses each of said one or more software services in said 
back-end component by communicating through said abstraction layer 
component, and 

said abstraction layer component provides built-in identity 
management that accepts a single sign on from a user and uses said single sign on 
to identify said user to each of said one or more software services and each of said 
more than one software application. 

In the July 9, 2008 Office Action, independent claim 1 was rejected under 35 U.S.C. 
§ 1 {)3(a) as being unpatentable over Ram in view of Meredith. Applicants submit that amended 
independent claim 1 is patentable over Ram and Meredith, as discussed below. 

Amended claim 1 requires a front-end component comprising more than one software 
application, a back-end component comprising one or more software services, and "absfraction 
layer component [that] provides standardization of back end services such that each of said more 
than one software application in said front-end component accesses each of said one or more 
software services in said back-end component by communicating through said abstraction layer 
component." Neither Ram nor Meredith shows or suggests this feature of amended claim 1. 

Ram is deficient for several reasons. Ram is directed to a "graphical front end system for 
real time security trading" (See Ram, Absfract). Ram recognizes that several prior art security 
trading configurations exist, such as one involving a proprietary front-end with optional 
middleware at the back-end side (see Ram, FIG. 1 ) or another involving a browser-based front- 
end with a web server and optional middleware at the back-end side (see Ram, FIG. 2). 
Apphcants recognized this as well in stating in the specification that: 

Typically, front-end business applications have been integrated with back-office 
host and network-based applications through a complex and non-standard set of 
APIs, adapters, and services. This may be thought of as a product-driven 
approach, since it has multiple products interfacing with the back office, each 

through its own set of integration, access, and security mechanisms 

Regarding the back-end, there may be multiple vendor-supported middleware 
solutions in place, and there may be direct couphng of apphcations to an 
individual connectivity utility. (Apphcants' specification as filed, p.l, t [0002] - 
[0004]) (emphasis original). 
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Applicants' disclosed technology specifically moves away from the use of complex and non- 
standard set of integration, access, and security mechanisms. As applicants' specification 
explains: 

One goal of [applicants' disclosed technology] was to move from a product- 
driven model that consisted of multiple products interfacing with a back office 
through their own integration, access, and security mechanisms (depicted in FIG. 
2) to a channel-driven model that enables multiple products to interface with a 
back office in a consistent and scalable manner (see FIG. 3). (Id., p.l 1, H [0091]). 

In contrast to applicants' disclosed technology, Ram does not move away from the use of 
complex and non-standard set of integration, access, and security mechanisms. On the contrary, 
Ram embraces it Ram's graphical front end system for real time security trading is itself one 
particular configuration of a complex and non-standard set of integration, access, and security 
mechanisms. Ram does not recognize the problem of a product-driven approach, and thus, 
nowhere does Ram show or suggest multiple software applications in a front-end component 
accessing back-end software services through a common absfraction layer component , as 
required in applicants' amended claim 1 . As the Examiner knows, a "prior art reference must be 
considered in its entirety, i.e., as a whole, including portions that would lead away from the 
claimed invention." (MPEP § 2141.02(VI)). Applicants submit that when considered in its 
entirety. Ram leads away from and fails to disclose applicants' amended claim 1, which requires 
an "abstraction layer component [that] provides standardization of back end services such that 
each of said more than one software application in said front-end component accesses each of 
said one or more software services in said back-end component by communicating through said 
abstraction layer component." The Examiner contended in the page 3 of the Office Action that 
applicants' abstraction layer component of claim 1 is shown in Ram, Fig. 4, by the Object Layer 
48. Applicants respectfully submit, however, that this is a mischaracterizafion of Ram's Object 
Layer. Rather, Ram's Object Layer is part of the software application in the front-end. Ram's 
Object Layer is not "an abstraction layer component that communicates with each of said more 
than one software application in said front-end component," as required by applicant's claim 1, 
because Ram's Object Layer is itself a part of a software application in the front-end. 

Meredith also does not show or suggest an "absfraction layer component [that] provides 
standardization of back end services such that each of said more than one software application in 
said front-end component accesses each of said one or more software services in said back-end 
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component by communicating through said abstraction layer component," as required by 

amended claim 1 . Meredith is directed to a "program ... for representing protocol-based 

apphcations as processes" (Meredith, Abstract). In page 4 of the Office Action, the Examiner 

contended that applicants' abstraction layer component of claim 1 is shown in Meredith, Fig. 3 A, 

by the Hardware Abstraction Layer 301. Applicants respectfully disagree. Meredith, referring to 

Fig. 3A, describes that: 

Subjacently coupled to the operating system 342 is a hardware abstraction layer 
301 . The hardware abstraction layer 301 is an application programming interface 
for use by programmers to access devices of the hardware system 344 (such as the 
computing device 302, the cellular phone 334, and the desktop computer 336). 
The operating system kernel 303A ... is designed to manage memory, files, and 
peripheral devices (via the hardware abstraction layer 301). (Meredith, p.5, Tf 
[0044]). 

This description in Meredith shows that Meredith's operating system accesses hardware 
components via a hardware abstraction layer. This is clearly not the same as software 
applications in a front-end component accessing software services in a back-end component by 
communicating through an abstraction layer component, as required by applicants' amended 
claim 1 . Accordingly, applicants submit that Meredith also fails to show or suggest an 
"abstraction layer component [that] provides standardization of back end services such that each 
of said more than one software application in said front-end component accesses each of said one 
or more software services in said back-end component by communicating through said 
abstraction layer component," as required in amended independent claim 1. 

In addition to the foregoing, neither Ram nor Meredith shows or suggests applicants' 
feature in amended claim 1 of an "abstraction layer component [that] provides built-in identity 
management that accepts a single sign on from a user and uses said single sign on to identify said 
user to each of said one or more software services and each of said more than one software 
application." 

Because both Ram and Meredith fail to show the abstraction layer component of 
amended independent claim 1, amended independent claim 1 is patentable over Ram and 
Meredith, either individually or in combination. Accordingly, applicants submit that 
independent claim 1 is allowable. Claims 2-3, 6-13, and 15-16 depend upon independent claim 
1 . The rejections of the dependent claims are traversed because "[i]f an independent claim is 
nonobvious under 35 U.S.C. 103, then any claim depending therefrom is nonobvious." (MPEP 
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§ 2143.03). Additionally, dependent claims 2-3, 6-13, and 15-16 are allowable for depending 
upon an allowable base claim. 

Applicants' silence with respect to the particular rejections of dependent claims 2-3, 6-13, 
and 15-16 should not be construed as a concession that the features of such claims are shown in 
the cited references. Rather, appHcants' silence is based on the belief that the foregoing 
adequately traverses the rejections of the dependent claims. Applicants hereby reserve the right 
to specifically address and traverse the rejections of the dependent claims in the future. 

Claims 17-27. 31-33, and 35-36 

Amended independent claim 17 recites: 

17. A system for linking more than one software application in a front-end 
component and one or more software services in a back-end component, 
comprising: 

a vendor connectivity component; 

a business integration component; 

a security component, wherein said security component provides identity 
management that accepts a single sign on from a user and uses said single sign on 
to identify said user to each of said more than one software appUcation and each 
of said one or more software services; 

a utility component; and 

a back end connectivity component, wherein said back end connectivity 
component enables each of said more than one software application in said front- 
end component to access each of said one or more software services in said back- 
end component by communicating through one standardized application program 

interface. 

in the .luly 9, 2008 Office Action, independent claim 17 was rejected under 35 U.S.C. 
§ 1 03(a) as being unpatentable over Ram in view of Meredith. (See Office Acfion, p. 7-8). 
Applicants submit that amended independent claim 17 is patentable over Ram and Meredith, as 
discussed below. 

Amended claim 1 7 requires "a back end connectivity component, wherein said back end 
connectivity component enables each of said more than one software appUcation in said front- 
end component to access each of said one or more software services in said back-end component 
by communicating through one standardized application program interface." Neither Ram nor 
Meredith shows or suggests this feature of amended claim 17. 
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Ram is deficient for several reasons. Ram is directed to a "graphical front end system for 
real time security trading" (See Ram, Abstract). Ram recognizes that several prior art security 
trading configurations exist, such as one involving a proprietary front-end with optional 
middleware at the back-end side (see Ram, FIG. 1) or another involving a browser-based front- 
end with a web server and optional middleware at the back-end side (see Ram, FIG. 2). 
Applicants recognized this as well in stating in the specification that: 

Typically, front-end business applications have been integrated with back-office 
host and network-based applications through a complex and non-standard set of 
APIs, adapters, and services. This may be thought of as a product-driven 
approach, since it has muhiple products interfacing with the back office, each 
through its own set of integration, access, and security mechanisms. . . . 
Regarding the back-end, there may be multiple vendor-supported middleware 
solutions in place, and there may be direct coupling of applications to an 
individual connectivity utility. (Applicants' specification as filed, p.l, t [0002] - 
[0004]) (emphasis original). 

Applicants' disclosed technology specifically moves away from the use of complex and non- 
standard set of integration, access, and security mechanisms. As appUcants' specification 
explains: 

One goal of [applicants' disclosed technology] was to move from a product- 
driven model that consisted of multiple products interfacing with a back office 
through their own integration, access, and security mechanisms (depicted in FIG. 
2) to a channel-driven model that enables multiple products to interface with a 
back office in a consistent and scalable manner (see FIG. 3). (Id., p.ll, t [0091]). 

In contrast to applicants' disclosed technology. Ram does not move away from the use of 
complex and non-standard set of integration, access, and security mechanisms. On the contrary. 
Ram embraces it - Ram's graphical front end system for real time security trading is itself one 
particular configuration of a complex and non-standard set of integration, access, and security 
mechanisms. Ram does not recognize the problem of a product-driven approach, and thus, 
nowhere does Ram show or suggest multiple software applications in a front-end component 
accessing back-end software services through one standardized application program interface , as 
required in applicants' amended claim 17. As the Examiner knows, a "prior art reference must 
be considered in its entirety, i.e., as a whole, including portions that would lead away from the 
claimed invention." (MPEP § 2141.02(VI)). Applicants submit that when considered in its 
entirety. Ram leads away from and fails to disclose applicants' amended claim 17, which 
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requires "a back end connectivity component, wherein said back end connectivity component 
enables each of said more than one software apphcation in said front-end component to access 
each of said one or more software services in said back-end component by commimicating 
through one standardized apphcation program interface." 

Meredith also does not show or suggest "a back end connectivity component, wherein 
said back end connectivity component enables each of said more than one software application in 
said front-end component to access each of said one or more software services in said back-end 
component by communicating through one standardized application program interface," as 
required by amended claim 17. Meredith is directed to a "program ... for representing protocol- 
based applications as processes" (Meredith, Abstract). In page 8 of the Office Action, the 
Examiner contended that applicants' back end connectivity component of claim 17 is shown in 
Meredith, Fig. 3 A, by the Hardware Abstraction Layer 301. Applicants respectfully disagree. 
Meredith, referring to Fig. 3A, describes that: 

Subjacently coupled to the operating system 342 is a hardware abstraction layer 
301 . The hardware abstraction layer 301 is an application programming interface 
for use by programmers to access devices of the hardware system 344 (such as the 
computing device 302, the cellular phone 334, and the desktop computer 336). 
The operating system kernel 303A ... is designed to manage memory, files, and 
peripheral devices (via the hardware abstraction layer 301). (Meredith, p.5, T[ 
[0044]). 

This description in Meredith shows that Meredith's operating system accesses hardware 
components via a hardware abstraction layer. This is clearly not the same as software 
applications in a front-end component accessing software services in a back-end component by 
communicating through one standardized application program interface, as required by 
applicants' amended claim 17. Accordingly, applicants submit that Meredith also fails to show 
or suggest "a back end connectivity component, wherein said back end connectivity component 
enables each of said more than one software application in said front-end component to access 
each of said one or more software services in said back-end component by communicating 
through one standardized application program interface," as required in amended independent 
claim 17. 

In addition to the foregoing, neither Ram nor Meredith shows or suggests applicants' 
feature in amended claim 17 of "a security component, wherein said security component 
provides identity management that accepts a single sign on from a user and uses said single sign 
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on to identify said user to each of said more than one software application and each of said one 
or more software services." 

Because both Ram and Meredith fail to show the back end connectivity component or the 
security component of amended independent claim 17, amended independent claim 17 is 
patentable over Ram and Meredith, either individually or in combination. Accordingly, 
applicants submit that independent claim 17 is allowable. Claims 18-27, 31-33, and 35-36 
depend upon independent claim 17. The rejections of the dependent claims are traversed 
because "[ijf an independent claim is nonobvious under 35 U.S.C. 103, then any claim 
depending therefrom is nonobvious." (MPEP § 2143.03). Additionally, dependent claims 18- 
27, 3 1 -33, and 35-36 are allowable for depending upon an allowable base claim. 

Applicants' silence with respect to the particular rejections of dependent claims 18-27, 
31-33, and 35-36 should not be construed as a concession that the features of such claims are 
shown in the cited references. Rather, applicants' silence is based on the beUef that the 
foregoing adequately traverses the rejections of the dependent claims. Applicants hereby reserve 
the right to specifically address and traverse the rejections of the dependent claims in the future. 
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Conclusion 



In view of the foregoing, applicants submit that claims 1-3, 6-13, 15-27, 31-33, and 35-36 
are allowable. Accordingly, reconsideration and allowance of these claims are respectfully 

requested. 

No fee is believed due in connection with this Reply other than the Request for 
Continued Examination fee and one-month extension of time fee provided in page one of this 
paper. If any other fee is required, please charge such fee to Morgan, Lewis & Bockius LLP 
Deposit Account No. 50-0310. 

Dated: March 1 7, 2009 Respectfully submitted, 
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